翼鸥教育（ Classln）是一个教与学一体化的平台，全球150+个国家的6万多所学校与机构都选择在教与学场景中应用Classln。此外，还有TeacherIn、NOBOOK等教育科技产品。
今天的分享主要从四部分展开：
第一，介绍翼鸥教育业务的存储现状及运维痛点；
第二，分布式数据库选型中的思考；
第三，对比业内两款比较流行的分布式数据库（TiDB、OceanBase）并结合翼鸥教育的业务场景进行测试；
第四，相关业务上分布式数据库的一些后续计划。
翼鸥教育的业务数据主要存储在MySQL，生产环境有近百套集群。数据库架构主要是MySQL主从架构，业务通过读写域名的方式访问数据库。同时，我们对Orchestrator做了定制化，能够管理MySQL主从的高可用。此外，我们也对一些核心的、数据量较大的集群做了分库分表。
在使用MySQL的过程中，我们遇到了三个主要的瓶颈。
第一，读写瓶颈。在疫情期间，翼鸥教育的业务翻倍，流量猛增，由于MySQL这样的单机版数据库无法像分布式数据库一样做到平滑的水平扩展，线上许多集群存在明显的读写瓶颈。
第二，容量瓶颈。翼鸥教育的数据增长很快，线上一些大表的性能问题逐渐暴露，随着数据量的增长，磁盘空间也慢慢地遇到了容量瓶颈。
第三，分库分表的历史遗留问题。由于一些历史原因，翼欧教育线上的分库分表分的并不彻底，分表之间也存在关联的一些操作。这些不合理、不规范的使用，导致数据库不断出现新的问题。
基于以上瓶颈，我们开始寻找新的数据库解决方案，并把目标投向了分布式数据库。
数据库选型时的五个考量因素
众所周知，分布式数据库自身具备水平扩展、高可用以及数据强一致等特点，除了这些能力，我们还十分看重它是否稳定、是否易运维、是否低成本、是否具备高性能、是否有丰富的生态。
稳定性。当我们将业务迁移至分布式数据库后，服务的稳定性是特别重要的。对于用户来说，他们或许并不在乎一个产品的底层存储是什么，但一定在乎服务是否足够稳定。
易运维。由于分布式数据库的门槛相对较高，如果它能提供一些智能化或平台化的运维工具，我们的运维人员所需的学习成本则会大大降低。
性能。我们希望能在有限的节点，且在可容忍的延迟范围内，考察一下分布式数据库能支撑多大的吞吐量。
生态。在将业务数据真正迁移到分布式数据库后，随着业务场景的丰富和数据量的增长，后续可能还会遇到各种各样的问题。如果数据库产品有一个良好的生态，就能帮助我们快速找到问题的解决方案。
成本。对于创业公司来说，降成本是一个无法避免的选型因素，就不再赘述了。
基于以上几个考察因素，翼鸥教育选择了解并测试业内流行的两款分布式数据库：TiDB和OceanBase（见图1）。
图1 TiDB 和 OceanBase的主要特点
TiDB
TiDB是一款支持混合事务处理和分析处理（Hybrid Transaction Analytical Processing，HTAP）的融合型数据库产品，可以做到水平扩容和缩容，也能达到金融级高可用能力，数据能够达到强一致。TiDB的表数据可以自动分裂，不需要DBA 介入，这个功能非常好用。同时，TiDB的社区也很活跃，当我们遇到问题时，在TiDB社区中基本能找到解决方法。
OceanBase
OceanBase 也拥有HTAP能力、并具备水平扩容或缩容、金融级高可用、数据强一致这三个特点。在 OceanBase 3.x版本中，如果表的数据比较大，需要我们进行手动分区，在 OceanBase 4.0 版本后，开始支持大数据自动分区。
我们认为 OceanBase 具备一个特别吸引人的能力，就是它支持多租户和资源隔离。一个集群在承担众多业务的情况下，做到业务不互相影响是非常重要的。而且，当我们遇到问题时，在 OceanBase 社区也能快速得到解决方案。此外我们发现 OceanBase 为了能让客户及时收到别人对自己提问、解答的回复，设置了消息提醒，通过服务号绑定社区帐号就能在我们的问题得到解答时第一时间看到。
在初步对TiDB和 OceanBase 进行考察后，我们根据翼欧教育的业务场景对两款数据库做了进一步的对比和测试。
TiDB和 OceanBase 的对比测试
我们的对比测试不局限于压力测试，因为两款数据库的压力测试都有极高的性能表现，甚至 OceanBase 在 TPC-C、TPC-H中都取得了世界级的突破，所以我们并不担心两款数据库的性能，而是从两个具体的业务场景中测试慢日志、CPU、事务延迟、数据同步、在线DDL、压测响应等。
👉 测试场景一：OceanBase 慢日志少，CPU、延迟指标表现平稳
第一个场景是翼鸥教育的某个MySQL业务集群（写峰值1.3k，读峰值3.5k，数据近 2TB），见图2 ，其特点是单库分表，多分表之间存在关联查询，且存在多分表插入和更新等操作。
图2 第一个测试场景概述
我们选择了TiDB v6.1 和 OceanBase v3.1.4进行测试与对比，测试所用的机器配置为3台 64C/256G/3T SSD。我们将线上的真实流量引入测试集群，测试的TiDB架构如图3所示，通过DM同步MySQL 的 dml操作，模拟写流量，写入TiDB cluster 。再通过TcpCopy复制MySQL读流量，回放到TiDB cluster来模拟读流量。对 OceanBase 测试的架构也与其类似，通过OMS采集写流量，通过TcpCopy拷贝和回放读流量，再回放到 OceanBase cluster。
图3 TiDB在第一个场景中测试的架构
通过对TiDB和 OceanBase 这两款产品的测试，我们得到了关于慢日志、CPU、延迟等方面的数据。
首先，对于慢日志，我们通过图4和图5可以看到。TiDB的慢日志比较多， OceanBase 也出现了慢日志，但次数较少。这是由于TiDB优化器不稳定，出现索引走错的情况，而 OceanBase 不支持倒序索引，其查询不走索引。
图4 TiDB 慢日志测试数据
图5 OceanBase慢日志测试数据
其次，对于CPU指标，我们可以从图6和图7中的数据得知，由于TiDB的延迟发生了一些波动， TiDB的CPU使用率也出现了较为明显的波动，而 OceanBase 的CPU使用率表现非常平稳。
图6 TiDB 的CPU数据
图7 OceanBase的CPU数据
最后来看延迟指标，见图8与图9，在整个测试过程中，TiDB出现了几次小的波动，OceanBase 整体较为稳定。
图8 TiDB的延迟数据
图9 OceanBase的延迟数据
从延迟和CPU这两个角度来看，OceanBase 都要优于TiDB。因为TiDB的数据在大于某个值后会自动拆分，数据会自动分散在各个节点上，而分表的查询或关联的更新基本走的都是分布式事务。OceanBase 支持本地事务，数据都在一个zone内，查询走的都是本地事务，所以其延迟比分布式事务低。
👉 测试场景二：OceanBase 较TiDB，数据清洗快2.74倍，数据同步快2.6倍
第二个测试场景是某业务需要从上游的多套MySQL集群汇集数据并清洗，数据清洗完成后提供线上服务。该业务场景的数据涉及多个上游集群，且清洗后的数据单表记录数最大达到30亿。
图10 第二个测试场景概述
我们还是采用TiDB v6.1和 OceanBase v3.1.4进行测试对比，机器配置仍为3台 64C/256G/3T SSD。在本次测试中，我们对两个数据库产品采用同一套清洗程序进行数据清洗，考察业务迁移后数据的压缩率、数据同步时间、数据清洗时间、在线 DDL用时、业务接口压测响应时间。
测试TiDB的架构见图11，通过DM把上游多个MySQL 表的数据同步到下游的TiDB cluster。在同步完数据后，业务程序会对同步过来的数据进行清洗，并将清洗完的数据写到本集群的新库中。
图11 TiDB在第二个场景中测试的架构
OceanBase 的测试架构如图12所示，与TiDB的测试架构类似。通过OMS采集上游的数据，再同步到 OceanBase cluster，业务程序也是在本集群进行数据的清洗，并将清洗完的数据写到本集群的新库中。
图12 OceanBase在第二个场景中测试的架构
经过测试，我们分别对比了TiDB和 OceanBase 在数据压缩率、数据同步时间、数据清洗时间、在线DDL用时、业务接口压测响应时间的表现。
1、数据压缩率对比。
从图13来看，TiDB和 OceanBase 对于单表各有优势。但前者的整体压缩率优于后者。
图13 数据迁移后的压缩率对比
2、数据同步时间对比。
我们并没有对同步的配置做优化，只是采用了默认的同步配置，发现TiDB所需的数据迁移时间是50674秒，OceanBase 只要19406秒。如图14所示，相当于 OceanBase比TiDB的数据同步快2.6倍。
图14 数据同步时间对比
3、数据清洗时间对比。
数据清洗时间也关乎上线耗时，是业务迁移中比较重要的节点。我们的测试结果显示，同一套清洗程序，TiDB的数据清洗用时是 OceanBase 的2.74倍，这意味着使用 OceanBase 的上线耗时比使用TiDB要短。因此，我们的研发人员对 OceanBase 的性能充满了信心和期待。
图15 数据清洗时间对比
4、表在线DDL用时对比。
如图16所示，OceanBase 在线DDL加索引的用时比TiDB 短很多，尤其对于一些大表的改表用时，测试结果的差距非常明显。这一对比结果，让我们感到非常意外。
图16 表在线DDL用时对比
5、接口压测相应时间对比。
我们选取了五个核心接口，采用相同的压测线程数对同一接口进行压测，经过测试，我们发现 OceanBase 的响应比TiDB的响应快两倍。
图17 接口压测响应时间对比
后续规划：核心业务迁移至OceanBase
基于此次分布式数据库的选型及测试、对比数据，我们制定了两个计划。
首先，翼鸥教育决定在核心业务中使用 OceanBase 数据库。目前，我们准备上线上面提到的Y业务。我们希望把MySQL集群数据汇聚到 OceanBase，通过租户隔离供大数据抽取和大后台业务使用。同时将部分增量数据通过OMS同步Kafka供大数据实时场景消费。此外，我们会陆续在其他业务中接入 OceanBase。
其次，翼鸥教育会重点关注 OceanBase 4.0版本，并尝试新功能。
OLAP能力。由于翼鸥教育后台的查询会严重拖累线上的输出性能，因此后续我们会将后台查询尝试迁移至 OceanBase 中。
OceanBase v4.0支持 I/O 隔离，也是我们想尝试的一个功能。
以前的分布式数据库对机器的规格要求较高，测试成本比较大，OceanBase v4.0支持单机分布式，对机器规格的要求更低，我们也会尝试用较低的机器配置来搭建 OceanBase，通过多租户的方式提供多套测试环境。
目前翼鸥教育的数据库监控都依赖于Zabbix，而Zabbix数据都存储在MySQL 中，接入的设备越来越多后，MySQL遭遇了读写瓶颈，OceanBase v4.0针对 Zabbix做了适配，我们会尝试把Zabbix监控存储也写到 OceanBase 中去。
好的，以上就是我的分享，谢谢大家。
邀你免费“旅游”1个月的OB君
点击图片 ↑↑ 查看详情
OceanBase 数据库免费试用来了！简单3步，即可免费试用1个月的1核4GB租户实例，还提供了10GB的免费存储空间。快来开启您的分布式数据库之旅~